TITLE OF THE INVENTION 

USER INTERFACE AND SYSTEM TO FACILITATE TELEPHONE CIRCUIT 

MAINTENANCE AND TESTING 

This is a continuation application of U.S. Patent Application No. 09/050,871, filed on 
March 3, 1998, which claims the benefit of U.S. Provisional Application No. 60/042,448, 
filed March 31, 1997, the contents of which are expressly incorporated herein by reference 
in their entireties. 

5 BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present Invention is directed to a user interface to facilitate telephone 
circuit maintenance and testing. In particular, the present invention is directed to a 
user interface that integrates disparate maintenance and testing applications and 
10 systems into a single common control interface. 

2. Acronvms 

The written description provided herein contains acronyms which refer to 
various telecommunications services, components and techniques, as well as features 
relating to the present invention. Although some of these acronyms are known, use 
15 of these acronyms is not strictly standardized in the art. For purposes of the written 
description herein, acronyms will be defined as follows: 

Advanced Interactive executive (AIX) 

Basic Rate Interface (BRI) 

Bellcore Client Company (BCC) 
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Circuit Access Code (CAC) 
Circuit ID (CKT) 

Circuit Layout Order Number (CLO) 
Digital Data System (DDS) 
5 Digital Speed Interpolation (DSI) 

Electronic Bonding (EB) 

High Level Language Application Programming Interface (HLLAPI) 
Inter-Exchange Carrier (IEC) 
ISDN Basic Rate Interface (BRI) 
10 Line Record Display (OSSLR) 

Local Area Network (LAN) 

Maintenance and Analysis Plan for Special Services (MAPSS) 
Manager Scratch Pad (MSP) 
Network Monitoring and Analysis (NMA) 
1 5 Network and Services Database (NSDB) 

Online Query System (OQS) 
Operational Support System (OSS) 
Order Number (ORD) 
Private Branch Exchange (PBX) 
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Tracking Key/Circuit Layout Order Number (TRK/CLO) 

Transmission Control Protocol/Internet Protocol (TCP/IP) 

Trouble Report (TR) 

Work and Force Administration (WFA) 

Work and Force Administration-Control (WFA/C) 

3. Background Information 

Conventionally, in order for service personnel to perform trouble-shooting, 
billing updates and testing of circuits, the service personnel must perform these tasks 
on separate systems, each of which have a different interface. The various user 
interfaces require the service personnel to access multiple terminals and to memorize 
multiple passwords for each system. Further, service personnel need to familiarize 
themselves with the differing interfaces and functional flows of the different systems. 
In addition to the above, the conventional systems are not universally provided with 
an interface to communicate and transfer information to other systems. 

SUMMARY AND OBJECTS OF THE INVENTION 

Accordingly, an object of the present invention is to provide a user interface 
and system that integrates disparate maintenance and testing systems and applications 
into a single common control interface. 
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Another object of the present invention is to provide a single user interface and 
system that interacts with Work Force and Administration (WFA) systems, 
Operations Support Systems (OSS), Network Monitoring and Analysis (NMA) 
systems, and REACT 2001 systems. 
5 Yet another object of the present invention is to provide an interface and 

system to perform a remote testing of analog services, digital data system (DDS) and 
digital speed interpolation (DSI) services, and ISDN Basic Rate service. 

Yet a further object of the present invention is to provide an interface and 
system to access ISDN switches to perform standard trouble isolation testing. 
10 A further object of the present invention is to provide an interface and system 

to perform testing of ISDN switches in accordance with vendor-specific switch 
criteria. 

Still another object of the present invention is to provide an interface and 
system which substantially reduces the learning curve for service personnel 
1 5 performing remote testing. 

Yet another object of the present invention is to provide a user interface and 
system having point-and-click/cut-and-paste capabilities, such that users may quickly 
and easily process trouble reports from creation of the trouble report at a point of 
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origin to the close-out stage, and such that users may quickly and easily process 
rebate information and billing information. 

In accordance with the above-listed objects, there is provided a user interface 
and system which provides a single, user-friendly, common interface to login and 
5 perform testing, trouble-shooting and billing updates. The user interface and system 
are adapted to dynamically monitor work lists on a user-controlled basis with 
individual, terminal-specific customization. 

In addition to providing an interface to Work Force and Administration 
(WFA), Operations Support Systems (OSS) and REACT 2001 systems, the system 

1 0 may selectively store customer trouble report data for retrieval during system outages 
to provide continuous access to customer data. The system may initiate a remote test 
session into the appropriate REACT 2001 host processor in an environment where 
multiple REACT 2001 host processors are connected to a wide area network. The 
system may also perform inward and outward dispatches for resolving network 

15 problems, control billing and rebate functions, and to perform trouble report 
restoration. The system may also be adapted to provide audio alerts in accordance 
with selected events, for example, receipt of a trouble report indicating problems in 
critical special services circuits. Such an audio alert may comprise, for example, a 
signal sent to an administrative personnel's pager. The system may also be provided 
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with online help and tutorial references to quickly provide users with information. 
Further, the system may be adapted to interface with other conventional systems, such 
as, for example, OPSINE and TIRKS. 

In accordance with another aspect of the present invention, the user interface 
5 and system is adapted to interact with Network Monitoring and Analysis (NMA) 
systems and Operations Support Systems (OSSs) to test ISDN Basic Rate Interface 
(BRI) lines via the serving digital (ISDN) switch. The system may access the serving 
ISDN switch via the NMA interface and perform standard trouble isolation testing oh 
the BRI lines. The ISDN switches may comprise, for example, Lucent 5ESS and 

1 0 Siemens EWSD switching platforms . 

The user interface and system of the present invention may utilize point-and- 
click functionality to speed the testing process and provide an easy, straightforward 
interface. The user interface and system also provides channel switch access to 
NMA, which provides for a secure connection to NMA, thus eliminating remote login 

15 security concerns. The user interface and system may be provided with a queuing 
function to queue requests to the ISDN switches, thus providing for efficient 
utilization of the limited numbers of switch access ports. In addition to the above, the 
system may automatically determine the type (i.e., vendor) of the ISDN switch 
undergoing testing once the BRI directory number is submitted. Once the type is 
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determined, the system may automatically initiate the appropriate testing commands 
based on input provided by the user. Further, the system and interface includes ISDN 
BRI tests, which may be accessed by pull-down menus. In addition, other ISDN BRI 
tests may be added as necessary. The user may use the system and user interface to 
5 transfer data (e.g., test results) from the ISDN switch to WFA for auditing and 
tracking. 

The above-listed and other objects, features and advantages of the present 
invention will be more fully set forth hereinafter. 

According to an object of the present invention, an apparatus is provided for 
10 integrating a plurality of disparate systems. The apparatus has a common control 
interface, an inputting device for entering data required by the plurality of disparate 
systems into the common interface, and means for transferring the data from the 
common control interface to at least one system of the plurality of disparate systems. 
The apparatus further comprises a user login system that logs a user onto the common 
1 5 control interface and permits usage of the plurality of disparate systems. 

According to a feature of the present invention, the plurality of disparate 
systems comprise maintenance and testing systems. The testing systems perform 
remote testing of analog services and/or ISDN switches. 
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According to an advantage of the instant invention, the common control 
interface comprises a user interface having point-and-click/ cut-and-paste capabilities. 

According to another object of the present invention, an apparatus is disclosed 
for telephone circuit maintenance and testing, comprising a control interface in which 
5 a user enters data, a telephone circuit maintenance and testing interface that receives 
data from the control interface, and a tester, that is controlled by the telephone circuit 
maintenance and testing interface, that tests predetermined telephone parameters. The 
tester performs a remote testing of analog services and/or ISDN switches. In this 
regard, the testing of ISDN switches is performed in accordance with vendor-specific 
10 switch criteria. The control interface comprises a first window for logging on and 
logging off the control interface, and a second window for bringing up screens 
necessary for performing proper maintenance analysis. 

According to an advantage of the instant invention, a GUI interface is provided 
that facilitates the entry of the data. 
15 According to another feature of the invention, the GUI interface provides 

point-and-click and cut-and-paste capabilities to the user. 

Another advantage of the present invention is that the control interface 
automates the sending and receiving of data between the control interface and the 
telephone circuit maintenance and testing interface. 
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Still another object of the present invention is to provide a user interface for 
use with a telephone circuit maintenance and testing system, that comprises a menu 
bar, which contains a plurality of menus required by a user to log on the system, log 
off the system, and handle routine setup parameters, and a toolbar from which a 
5 plurality of screens can be called to input data required for a trouble ticket. The data 
is used for proper maintenance analysis by an automated test tool that performs an 
automated test on at least one parameter of a telephone system. Further, a data 
transporter is provided that transfers the data input via the toolbar to a WFA/C 
interface, in which the WFA/C interface controls the automated test tool. The 
1 0 automated test tool performs digital testing and/or analog testing. 

a still further advantage of the present invention is that a converter is provided 
that converts the data input via the toolbar to a form usable by a WFA/C interface that 
facilitates telephone circuit maintenance. The converted data is exchanged between 
the user interface and the WFA/C interface. 
15 The present disclosure relates to subject matter contained in provisional 

application number 60/042,448, filed on March 31, 1997, which is expressly 
incorporated herein by reference in its entirety. 

BRIEF DESCRIPTION OF THE DRAWINGS 
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The foregoing and other objects, features, and advantages of the invention will 
be apparent from the following more particular description of a preferred 
embodiment, as illustrated in the accompanying drawings which are presented as non- 
limiting examples, in which reference characters refer to the same parts throughout 
5 the various views, and wherein: 

Fig. 1 A is a block diagram illustrating various components and connections 
of a system of the present invention; 

Fig. IB is a block diagram illustrating the connection between the system of 
the present invention and WFA. 
1 0 Fig. 2 is a flow chart of an initialization routine of the GRETA application of 

the present invention; 

Fig. 3 is a flow chart of the main looping process of the GRETA application 
of the present invention in which a user selects an activity to be performed; 

Figs. 4-63 are flow charts of the user selectable activities which may be called 
1 5 from the main looping process of Fig. 3 ; and 

Figs. 64-65 are flow charts of the HILDA application, as called by GRETA, 
or from a UNIX prompt. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
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The present invention will now be described below. For the convenience of 
the reader, additional components and information will be hereinafter described with 
reference to the terminology and references utilized in the above-noted documents. 

1. Hardware Detail and Components 

As shown in Figs. 1A and IB, GRETA interfaces with WFA, HILDA and a 
REACT 2001 Host. The REACT 2001 Host System is a product of Hekimian, Inc., 
located in Rockville, Maryland. The WFA Host is a product of Bellcore, located in 
Murray Hill, New Jersey. 

a connection between GRETA and the WFA Host may be provided via a 
TCP/IP socket (see Fig. IB) and, for example, an IBM 3270 interface of an IBM 
RS6000 computer, where GRETA emulates a printer port to the WFA host. Such 
hardware is known to those skilled in the art, and thus, is not described in detail 
herein. The connection between GRETA, the REACT 2001 Host and the HILDA 
Host, and the connection between HILDA and the NMA Host may also be provided 
by TCP/IP protocols. In particular, GRETA may connect to the REACT 2001 Host 
and HILDA via TCP/IP or Telnet, and HILDA may connect to the NMA Host via 
TCP/IP or Telnet. It is noted that Telnet will provide the user with an interface to 
execute procedures that are run on the remote device. 
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Although shown in Fig. 1 A as separate systems, GRETA and HILDA may be 
provided on the same client/server platform, wherein information and data are 
transferred via a file access or memory access. In addition, GRETA provides a 
system wherein a user may login and utilize a single password to access other 
5 systems, with no need to login and enter a password for each of the other systems. 

As denoted by the double arrows in Fig. 1A, GRETA may support 
simultaneous sessions with multiple WFA Hosts. 
2. Software Detail and Functional Flow 

As noted above, the user interface provides a mechanism to transfer data 
10 " among the various applications and platforms connected to GRETA, such that data 
may be quickly and easily accessed to speed the process by which customer trouble 
reports are resolved. 

GRETA, which was written using a High Level Language Application 
Programming Interface (HLLAPI) and TCP/IP, automates the sending and receiving 
15 of data from the WFA/C interface. GRETA connects to a plurality of servers and uses 
its GUI interface to communicate with WFA/C. GRETA's scheme allows users to 
eliminate the need to perform redundant and tedious actions within WFA/C by 
clicking a button, clicking a menu option, or hitting the "ENTER" ("RETURN") key 
on a keyboard. Information is laid out in a list and scrolling window form. 
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Two main windows are displayed when GRETA is executed. The first 
window is the menu bar, which contains a series of menus that the user will need tp 
handle routine setup, logging on and off the system, choosing colors, displaying 
already selected windows, and bring up on-line documentation. The second window 
5 is the toolbar. The toolbar is a row of buttons that can bring up the screens necessary 
for proper maintenance analysis on a given trouble ticket, bring up windows to 
specify circuits and ticket numbers, and call a pick-up command. From the toolbar, 
the user can also start up Hilda, which is an automated ISDN test tool,jOREACT 2001 
GUI and a semi-automatic testing window. Both the menu and the taskbar are always 

1 0 open and can only be closed when GRETA is terminated. 

The ticket window in GRETA is opened from the toolbar and gives the user 
the ability to view multiple trouble tickets within different centers, function level 
codes, and color. Unlike WFA/C, GRETA automatically updates the ticket display 
window, so the user does not have to worry if the most current ticket list is being 

15 viewed. The ticket window also allows the user to sort the ticket according to the 
ticket status, bring up a trouble report screen, and print the ticket list, all with the click 
of a mouse button. 
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Another significant screen is the trouble report screen. The user can point-and- 
click to the screens that will allow quick and accurate handling of the trouble ticket, 
including the adding of remarks, checking the status, etc. 

Fig. 2 illustrates the flow chart of GRETA. According to the present invention, 
5 user default files are read in (inputted) at step SI when the system is first initialized. 
Thereafter, a series of default files, such as, for example, a file related to authorized 
users, are inputted (step S3), and a menu and taskbar are displayed on, for example, 
a display associated with the computer system (step S5). At this point, GRETA 
begins a Main Application Event Loop Process (step S7), which is illustrated in 
10 greater detail in Fig. 3. 

As shown in Fig. 3, the Main Application Event Loop Process enables the user 
to select from a plurality of activities. These activities (routines/options) include, but 
are not limited to: a routine to select and setup a desired printer (step SI 00); an 
employee activity routine (step S200); a time sheet routine (step S300); a GRETA 
15. size routine (step S400); a GRETA color routine (step S500); a GRETA bell sounding 
routine (step S600); an e-mail routine (step S700); a GRETA color setting routine 
(step S800); a Work Force and Administration (WFA) backup routine (step S900); a 
WFA screens routine (step SI 000); a GRETA security routine (step SHOO); a 
window cascade routine (step S 1 200); a GRETA help routine (step S 1 300); a window 
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select routine (step S1400); a save placement routine (step SI 500); an about routine 
(step SI 600); a maintenance ticket window routine (step SI 700); a ticket specify 
routine (step S 1 800); a specify circuit window routine (step S 1 900); a pickup ticket 
routine (step S2000); an OSSTR screen routine (step S2100); a test routine (step 
5 S2200); a semi-automatic test routine (step S2300); a WFA screens by ticket routine 
(step S2400); and a close application routine (step S2500). 

Each activity routine will now be described in detail below. 

Printer Setup 

The printer setup activity routine of the present invention is illustrated in Fig. 

10 5. 

When the printer setup routine is executed, step SI 02 is performed to display 
a list of printers on an associated monitor. Meanwhile, a determination is made as to 
whether the user selected a close (exit) button on the display (step S 104). If the close 
button was selected, processing proceeds to exit the printer setup routine (step S 106). 
15 On the other hand, if the close button was not selected, processing proceeds to 

step S 108 to determine whether a printer has been selected. As long as a printer has 
not been selected, the list of available printers to select from is displayed on the 
monitor (steps SI 02 to SI 08 is continuously repeated). However, once a printer is 
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selected from the displayed list, step SI 10 is executed to confirm the selected printer, 
and a user printer file of the selected printer is created at step SI 12. 

Thereafter, processing returns to step SI 02 to display the list of available 
printers and determine whether the close (exit) button has selected. 
5 Employee Activity 

The employee activity routine is illustrated in Fig. 4. 

When the employee activity routine is selected (step S200), a determination is 
made as to whether a user is logged into the system (step S202). If the user is logged 
in, processing proceeds to obtain WFA Employee Activity (OSSEA) information and 
10 determine whether, the OSSEA is successfully obtained (steps S204 and S206). 

If the OSSEA is not successful, an error message is produced and the user is 
permitted to edit the user input (steps S208 and S210). However, if the OSSEA was 
successful, step S208 is skipped, and thus, the error message is not produced. 

The WFA request is then processed (step S212) and a determination is made 
15 as to whether the "EXIT" button has been selected (step S214). When the "EXIT" 
button is not selected, a determination is made to determine if the time sheet activity 
should be executed. If the determination is affirmative, the employee activity routine 
is terminated and the time sheet activity is executed (steps S214, S216, S218 and 
S300). On the other hand, if the determination at step S216 (e.g., whether to execute 
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the time sheet routine) is negative, processing loops back to step S210 to permit 
editing of the user input. 

However, if it is determined that the "EXIT" button has been selected, 
processing terminates (step S220) without executing the time sheet routine. Similarly, 
5 if it was determined at step S202 that a user is not logged in, processing exits. 

Time sheet 

Fig. 1 1 illustrates the time sheet activity routine performed by the present 
invention. According to this routine, an initial determination is made as to whether 
the user is logged in. When it is determined that the user is logged in (step S3 02), 
1 0 WFA VOS 1 SIGN information (e.g., sign on, sign off information) is obtained. If the 
information is valid, the user is able to edit the input data, which is then processed by 
the WFA (steps S300 to S2310) 

If it was determined that the WFA VOS 1 SIGN information is invalid, an error 
message (step S3 07) is produced prior to allowing the user to edit the input. 
1 5 After the information is processed, it is determined, at step S3 12, whether the 

"EXIT 11 button has been selected. When the "EXIT" button is selected, processing 
proceeds to step S3 14 to exit the time sheet routine. Otherwise, processing loops back 
to S308 to allow the user to edit the input data. 
GRETA Size 
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Fig. 6 illustrates the GRETA size activity routine that can be selected from the 
program illustrated in Fig. 2. According to this routine, the user is able to select 
desired system size parameters, such as, for example, the desired size of the menus 
and toolbar (steps S402 and S404). Thereafter, step S406 is executed to exit the 
5 GRETA size routine. 

GRETA Colors 

The GRETA color setting activity routine, which enables the user to select 
desired screen display colors, is illustrated in Fig. 8. As shown in Fig. 8, a plurality 
of colors available to the user is displayed on the monitor. The user selects the 
1 0 desired color(s), and then a determination is made as to whether the user accepts the 
selected colors, or wishes to exit without making a color selection (steps S502 and 
. S504). 

If the user indicates that the colors have been selected (e.g., step S504 is 
"OK"), processing proceeds to step S506 to set the selected colors. Thereafter, the 
15 displayed menus, toolbar, ticket window, etc. are redrawn using the desired colors 
selected by the user, and this routine exits (steps S508 and S510). 

On the other hand, if it is determined at step S504 that the user does not wish 
to change (select) display colors, processing skips steps S506 and S508, and exits 
without changing the display colors. 
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GRETA Bell 

Fig. 9 illustrates the activity routine that is executed to provide either a visual 
or audible indication (alarm) to the user when, for example, an error occurs. In this 
routine, the user selects whether an audible (e.g., beep through a speaker) or a visual 
5 (e.g., monitor screen color change) alarm is to be provided at step S602. If the 
audible option is selected, the system is set to initiate an audible beep through an 
associated speaker when any changes are made (steps S604, S606 and S608). 
However, if the visual option is selected at step S604, processing proceeds to step 
S610 to activate the maintenance ticket border color changes in accordance with the 
10 ticket list changes. 

GRETA Default E-Mail 

Fig. 10 illustrates the activity routine for the user to set his/her default e-mail 
address. If the user selects this activity, the user is shown an e-mail window, with the 
cursor located at a position where the user enters his/her e-mail address. After 
15 entering the user's e-mail address, the user selects an "OK" button on the e-mail 
window. This results in the user's e-mail address being saved to a user file associated 
with the user for future use, and the exiting of routine (steps S702 to S708). 
However, if the user selects an "EXIT" button instead of the "OK" button, the routine 
exits without saving the e-mail address to the user file. 
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GRETA Exit 

This activity routine, illustrated in Fig. 7, is one of the activities available in 
the GRETA application shown in Fig. 2 and enables the user to either exit the 
GRETA application, or to close the pop up window to, for example, make another 
5 selection in the GRETA program. According to this activity, a pop up window is 
displayed on the monitor, asking whether the user wishes to exit the program (step 
S802). If the user selects an "OK" button, step S804 is performed to exit the 
application. On the other hand, if the user selects a "CANCEL" button, step S806 is 
executed to close the pop up window without exiting the application. 
10 WFA Backup 

Fig. 33 illustrates the WFA backup routine that is performed by the present 
invention. When this option is selected by the user, a test is made to determine 
whether the index file has been found. If the index file is found, the indexed tickets 
are listed. Then, the selected backup is loaded to memory, and the index file is 
15 closed. 

When the OSSTR, OSSLOG, or OWDDOC activity is backed up, the selected 
ticket is backed up, and then the respective TR file, LOG file, or DOC file is read, and 
the respective OSSTR window, OSSLOG window, or OWDDOC window is brought 
up in a view only mode. 
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The backup activity routine writes all trouble report screens, OSSLOG screens, 
or OWDDOC screens that are viewed during the WFA/C up time to a file on a server 
before the mainframe is shut down. The trouble report, log and word document 
5 screens can then be viewed using a view-only window to review certain circuit or 
trouble ticket activities. 

WFA Screens By Circuit 

When the user selects the Bellcore Work Force and Administration - Control, 
the user is present with a series of activities to chose from. These options include, for 
10 example, OWDDOC; OSSCN; OSSCHI; OSSMG; OSSIMG; OSSHMD; OSSFF; 
OSSLR; OSSOSSTRE; and OSSOI. These activities are described in detail in "Work 
and Force Administration/Control (WFA/C) User Manual' 1 , published by Bellcore 
Practice . BR 190-513-323, Issue 8, May 1996, WFA/C 1.7, the subject matter of 
which is expressly incorporated by reference in its entirety herein, and thus, is not 
1 5 described in detail herein. 

a. OWDDOC 

The OWDDOC activity window is a word document window with text search 

capabilities. When this activity window is selected from the WFA/C Screens By 

Circuit, shown in Fig. 35, processing proceeds to the flowchart illustrated in Fig. 47, 

20 which permits a user to display a WORD document and circuit/WORD notes. The 
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WORD document shows the end-to-end layout of a designed circuit (message, special 
service, and carrier). The screen produced when this window is opened is illustrated 
at, for example, page 4-3 of the aforementioned "Work and Force 
Administration/Control (WFA/C) User Manual". 
5 In this activity, a WORD document is retrieved (step SI 00202), and a test is 

performed (step SI 00204) to determine whether the retrieval was successful. If an 
error occurred during the retrieval of the WORD document, an error message is 
produced (step SI 00206), and the OWDDOC window is closed (step SI 00208). 

If the document was successfully retrieved at step SI 00204, a document 
10 similar to that shown at page 4-3 of the aforementioned "Work and Force 
Administration/Control (WFA/C) User Manual" is brought up (step S 1 002 1 0). At this 
point, the user can enter data into the document. Thereafter, the user can select a 
Load To React activity routine (step S 100214, to be discussed below with respect to 
Fig. 41), a Test activity routine (step SI 002 16, to be discussed below with respect 
15 to Fig. 40), a word search activity routine (step S 1 002 1 8), or a print activity routine 
(step SI 00220). Alternatively, if the user is finished with the document, he/she can 
exit the OWDDOC window (step S 1 00208). 

The Load To React activity routine, illustrated in Fig. 41 , determined whether 
v an ISDN line or analog line is to be tested. In this routine, a test is initially performed 
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to determine whether the user is logged onto the(system. If the test results are 
affirmative, another test is performed to determine whether a ticket or circuit has been 
called up. If a circuit is called, a determination is made as to whether the circuit is an 
ISDN line. When the circuit is not an ISDN line, REACT 2001 is activated (steps 
5 S101214, S102214, S103214 and S104214). When it is determined that the circuit 
is an ISDN line, HILDA is activated to test the line (steps S101214, S102214, 
S103214andS105214). 

On the other hand, if it was detected, at step SI 022 14, that the document is a 
ticket, the WFA Process is called at step SI 062 14, to get a circuit ID, prior to testing 
1 0 whether the circuit is an ISDN line. Similarly, if it was determined at step S 1 0 1 2 1 4 
that the user is not logged in, an error message is produced (step SI 072 14) and 
processing opens a WFA/C Trouble Report/Activity (OSSTR) window (illustrated in 
Fig. 37), to be described below. 

The Test activity routine (SI 002 16) is shown in Fig. 40, and is similar to the 
1 5 Load To REACT activity routine. For an explanation of the operation of this routine, 
reference should be made to the Load to React activity routine. 
b.OSSCN 

When the Circuit Notes (OSCCCN) activity window (option) is selected, a 
window, similar to the window illustrated on page 8-7 of the aforementioned "Work 
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and Force Administration/Control (WFA/C) User Manual" is pulled up to allow the 
user to enter and update necessary circuit information in a free-text format. The 
flowchart for this activity is shown in Figs. 53 and 54. This screen allows the user to 
update, for example, circuit notes and customer name, address and telephone number 
5 for special services. 

In addition, the user is given the option of printing the data to a local printer, 
refreshing the display screen, updating the data displayed on the OSSCN screen 
(window), copying the data to another location, or exiting the OSSCN window. 

c. OSSCHI 

1 0 When the Circuit History (OSSCHI) activity window (see Fig. 55) is selected, 

the user is presented with a circuit history report. This report allows the user to view 
(and/or print) order and trouble report activities for a particular circuit, a sample 
OSSCHI window is shown at page 8-4 of the aforementioned "Work and Force 
Administration/Control (WFA/C) User Manual" . Thereafter, processing returns to the 

15 WFA/C Screens By Circuit. 

d. OSSML 

The WFA/C Multipoint Circuit List (OSSML) activity window (used to select 
circuit identifications), the flowchart of which is shown in Fig. 56, displays all 
segments of a multipoint circuit to a user of the system. This window (a sample of 
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which is illustrated at page 6-16 of the aforementioned "Work and Force 
Administration/Control (WFA/C) User Manual") lists all segments with partial circuit 
identifications that match a "backbone" circuit ID that was entered in a CKT field. 

e. OSSIMG/OSSHMD 

5 The flowchart for the OSSIMG and OSSHMD activities is shown in Fig. 57. 

The OSSIMG window (step SI 008) is used in an order screening process. This 
window, which is illustrated at page 5-2 of the aforementioned "Work and Force 
Administration/Control (WFA/C) User Manual" allows a user to display service order 
image data stored in the Network and Services Database (NSDB). 

10 The History Measurement Data (OSSHMD) activity (step SI 0 1 0) is used to 

display and update (input) Circuit History information, Maintenance and Analysis 
Plan for Special Services (MAPSS) inventory data, and work unit data after orders are 
completed in the Circuit History database, a sample of this window is shown at page 
8-2 of the aforementioned "Work and Force Administration/Control (WFA/C) User 

15 Manual". 

In both windows, after the user has input the appropriate data, the user is 
presented with the option of outputting the data to a printer, or exiting the window and 
returning to the WFA/C Screens by Circuit activity window. 

f. OSSFF 
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r 

The OSSFF activity window, the flowchart of which is illustrated in Fig. 58, 
is provided to enable the user to view the NSDB Facility-to-Circuit Database 
relationships. That is, the user can display the circuits riding directly on a given 
facility or display the facility that the given circuit is riding on. a sample OSSFF 
5 window is shown, for example, at page 4-67 of the aforementioned "Work and Force 
Administration/Control (WF A/C) User Manual" . 

g. OSSLR 

The Line Record Display (OSSLR) activity window is a "find only" screen that 
shows the entire line record for a given Circuit ID (CKT), Circuit Access Code 

10 (CAC), Order Number (ORD), or Tracking Key/Circuit Layout Order Number 
(TRK/CLO). Since this window is a "find only" screen, retrieved information may 
not be over typed and updated by the user. The flowchart for this activity window is 
illustrated in Fig. 59 and is shown, for example, at page 4-22 of the aforementioned 
"Work and Force Administration/Control (WFA/C) User Manual". 

15 h. WFA/C Trouble Report Entry fOSSTRE) 

The flowchart for the OSSTRE activity window (step S1016), shown in Fig. 
61, is provided to allow a user to enter a trouble report on a special device, a message, 
a carrier, and a non-designed service. The user can add a "miscellaneous" trouble 
report in this window. In addition, the user can add, update, cancel and transfer 
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trouble reports, a sample window is shown at page 6-2 1 of the aforementioned 11 Work 
and Force Administration/Control (WFA/C) User Manual' 1 , 
i. OSSOI 

The WFA/C Order Information (OSSOI) activity window is a two page screen 
5 that shows administrative, tracking and customer/premise order information. In 
addition, the user can also issue an auto-test request from this screen. The flowchart 
for this activity is illustrated in Fig. 60. Sample windows are illustrated at pages 5-26 
to 5-28 of the aforementioned "Work and Force Administration/Control (WFA/C) 
User Manual ". 

1 0 When the OSSOI window is opened, the user can select to go to the WFA/C 

Work Log (OSSLOG) window to display a detailed account of activities on an order 
or trouble report. This screen, which is a display-only screen, shows activities in 
date/time sequence with the most recent activity at the top. 

Alternatively, the user can select to go to the WORD Access (OWDDOC) 
15 activity screen, discussed above, or exit the OSSOI window. 
GRETA Security 

The Greta Security flowchart is illustrated in Fig. 12. When this activity 
window is selected by the user, a new menu is presented to the user. In the disclosed 
embodiment, the new menu provides five options from which to choose: 
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- a sign on option, 

- a sign off option, 

- an automatic sign on option, 

- a security file creation option, and 

5 - a password field update and sign on option. 

The Sign On option executes the flowchart illustrated in Fig. 13. In this 
routine, the user attempts to log onto the system and a determination is made as to 
whether the logon and password are valid. If the inputted data is valid, the user is 
given access to the system, a confirmation message is produced, and the program 
1 0 exits the Sign On window (steps S 1 1 0202 to S 1 1 02 1 6). Otherwise, an error message 
is produced and the program exits. 

The Sign Off option executes the flowchart illustrated in Fig. 14. In this 
routine, when the user logs off the system, a log off message is displayed, and then 
the system exists the Sign Off window (steps SI 10402 to SI 10408). On the other 
1 5 hand, if it is determined that the user is already logged off in this region (e.g., the user 
is not currently signed on the system), an error message is produced at step S 1 10410 
and the Sign Off window closes. 

The Automatic Sign On option executes the flowchart illustrated in Fig. 15. 
In this routine, an encrypted sign on file is read and processed to log onto the system. 
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If the encrypted file was successfully processed, a confirmation message is produced, 
and the Automatic Sign On window closes (steps SI 10602 to SI 10614). Otherwise, 
an error message is produced (step SI 10616) and the Automatic Sign On window 
closes without the user gaining access to the system. 
5 The Create Security File option executes the flowchart illustrated in Fig. 16. 

a determination is made as to whether an information file already exists for the user 
attempting to create a security file. If an information file does not exist, required 
information is entered by the user, which is then encrypted before this window closes 
(steps SI 10802 to SI 10810). Should the user make a mistake while inputting the 
1 0 required information, the user is given the option (step S 1 1 08 1 2) of re-entering the 
information by clearing all the edit fields. If it was determined at step S 1 10804 that 
an information file already exists on the user, the information file is loaded (except 
for the password) (step SI 10814), thus reducing the amount of data that needs to be 
inputted by the user. 

15 The Update Password File And Sign On option executes the flowchart shown 

in Fig. 17. This option is provided to allow the user to update his/her user profile for 
signing onto the system (steps SI 1 1002 to SI 1 1016). If the user makes a mistake 
while updating the user profile, the edit fields can be cleared (step SI 1 1018). 
Window Cascade 
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The Window Cascade activity option is illustrated in Fig. 18. This routine is 
executed when the user prefers to have the various windows stacked in a cascaded 
order. When this routine is run, step SI 202 instructs the system to cascade the 
various windows, as opposed to tiling the various windows. 
5 GRETA Help/Tutorial 

The G*eta Help/Tutorial option is illustrated in Fig. 22. This routine is 
executed when the user wishes to obtain assistance (help) with the operation of Greta. 
When this option is executed, step S 1302 is executed to activate a Mosaic Session that 
reads a HTML help file for display. It is noted that Mosaic runs independently of 
10 Greta. 

Window Select 

The flowchart for the Window Select activity option is illustrated in Fig. 19. 
This routine is executed to enable the user to activate the desired window (option). 
According to this routine, a list of available windows is displayed. If the user selects 
15 a desired window, the selected window is activated and the Window Select window 
closes (steps S4 1 02 to S 1 4 1 0). On the other hand, if the user decides against selecting 
a desired window, and instead selects a "£LOSE" button (step SI 404), the current 
window closes without selecting a new window to open, 

Save Placement 
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The Save Placement window (routine), illustrated in Fig. 20, operates to write 
the positions of the menu, toolbar, and maintenance ticket window to a file that is read 
when the GRETA application is started. That is, this file contains default information 
for the particular user, such as, for example, whether the windows should be tiled or 
5 cascaded, positions of the menu and toolbar, etc. 

GRETA About 

The Greta About Window routine is illustrated in Fig. 21. When this window 
is selected, information specific to Greta, such as, for example, the version number, 
program creation date and programmer's names are displayed. 

10 Maintenance Ticket Window 

The flowchart for the Maintenance Ticket Window is illustrated in Fig. 23. 
When this activity window is selected, the system connects to the Greta ticket 
manager (step SI 7002), to be discussed below. If a connection can not be established, 
the maintenance ticket window closes (steps S 1 7004 and S 1 7006). On the other hand, 

15 if a connection is established, a determination is made as to whether a user 
subscription file exists. If the user subscription file exists, the information contained 
in the file is provided to the Oreta ticket manager and the data sorted by the Greta 
ticket manager is dynamically updated (steps S 1 7008 to S 1 70 1 2). On the other hand, 
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if a user subscription file is not found, an error message is produced (steps SI 7008 
and S17014), and steps S17010 and S17012 are skipped. 

Thereafter, in the disclosed embodiment, the user is able to select from the 
following options: 
5 - Available Tickets Only 

- All Tickets 

- In Progress Tickets 

- Click On Ticket 

- Double Click On Ticket 
10 -Print Ticket 

- Ticket Colors 

- Refresh 

- Activate Set List 

- Close Maintenance Ticket Window 

1 5 Based upon the above, the user can select to update either all available tickets, 

all tickets or only those tickets that are in progress (steps SI 70 14, SI 70 16, or 
S 1 70 1 8). Thereafter, the Greta Ticket Manager connection is dropped (step S 1 7020), 
the connection is re-established (step SI 7022), and processing loops back to step 
S17010. 
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When the Activate Set List activity window is selected, the program illustrated 
in Fig. 24 is executed. First, the Greta manager connection is terminated (step 

51 70241) and then, the center and specific work group (FLC) file is selected (step 

5170242) . The user is then presented with the option of setting a list (step S170243), 
5 using a default list (step SI 70244) , saving a list (step SI 70245), or exiting. 

When the list set option is selected, the center and specific work group file 
selected at step SI 70242 is stored to the memory before processing proceeds to step 
S 170246. When the default option is selected, the user's center and specific work 
group selected at step SI 70242 is read into the memory before proceeding to step 
10 S 170246. If the save option is selected, the information selected at step S 170242 is 
saved to the user's center and specific work group file before processing proceeds to 
step S 170246. If the user elects to exit from this window, processing returns to step 
S17022inFig.23. 

At step SI 70246, the center and specific work group (FLC) list is provided to 
15 the Greta ticket manager, after which the Activate Set Limit Window is closed (step 
SI 70248, and processing returns to step SI 7022 in Fig. 23. 

When the Print option is selected, the program illustrated in Fig. 25 is 
executed. An initial determination is made as to whether a printer is defined. If the 
printer is defined, the current ticket is printed, and the print window exits (steps 
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S 170301 to S 170303). However, if it is determined at step S 170301 that a printer has 
not been defined, another window pops up to allow the user to select a printer (step 
S170304). 

When the Refresh activity option is selected, the program illustrated in Fig. 26 
5 is executed to resize the maintenance ticket window to show a maximum of 30 tickets 
(steps S 1 7026 1 and S 1 70262). 

When the Ticket Colors activity option is selected, the program illustrated in 
Fig. 27 is executed. When this window appears, the user is presented with a choice 
of new colors. The user can either: 
10 - accept general default colors (step SI 70282), or 

- select a user's default colors (step S 170283). 
The user is able to save the ticket colors to a file for future use (step SI 70284), and 
when the user clicks (selects) the "OK" button, the user's default colors (selected new 
colors) are activated (step 170285) and the window closes (step S 170286). It is also 
15 noted that the user can also exit this window without selecting the ticket colors. 

When the Click On Ticket option is selected, the flowchart illustrated in Fig. 
29 is executed. In this routine, a ticket that is clicked upon (using a mouse) is 
highlighted and placed in the system memory as an active ticket. Thereafter, 
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processing returns to the Maintenance Ticket Window of Fig. 23 (steps SI 70321 to 
SI 70323). 

When the Double Click On Ticket option is selected, processing proceeds in 
accordance with the flowchart shown in Fig. 30. Specifically, a ticket that is clicked 
5 upon is highlighted andplaced in the system memory as an active ticket. Thereafter, 
a determination is made as to whether the user is logged into the proper region. If the 
determination is affirmative, processing proceeds' to activate the WFA/C trouble 
Report/Activity (OSSTR) screen, which will be described below (sieps S 170341 to 
SI 70344). However, if it is determined that the user is not lodged into a proper 
10 region, an error message is produced and processing returns to the Maintenance 
Ticket Window of Fig. 23 (steps S170341 to S170343, S170345 and S170346). 

The user may also decide to close the Maintenance Ticket Window; When this 
option is selected, the flowchart shown in Fig. 28 is executed to close the 
Maintenance Ticket Window, after which the Greta Ticket Manager connection is 
15 terminated (steps S170061 and S170062). 
Greta Ticket Manager 

The Greta Ticket Manager (see Figs 62 and 63) is called by the Maintenance 
Ticket Window (at step SI 7002) of Fig. 23. In this routine, multiple connections are 
established to the WFA/C via TCP/IP sockets, a configuration file (e.g., greta.ctr) is 
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read, and then, a WFA/C Pending Trouble List (OSSPND) screen is brought up, via 
the TCP/IP sockets, for all centers and specific work groups (FLCs). Thereafter, the 
system waits for a predetermined period of time (e.g., 60 seconds) for requests from 
the Greta ticket window. After the time period elapses, a determination is made as 
5 to whether a center/specific work group (FLC) list, was requested. If the 
determination is negative, it is determined whether a new Greta user is online. If this 
determination is negative, the OSSPND screens for all defined centers and specific 
work groups (FLCs) are retrieved (steps S170021 to S170027). 

Next, another determination is made as to whether the Greta user is connected 
1 0 via the TCP/IP sockets. If the determination is positive, the , subscribers are updated 
(steps S170028 and S170029) and processing returns to step S170024. However, if 
the Greta user is not connected, step SI 70029 is skipped, and thus, processing returns 
to step SI 70024 without updating the subscribers. 

It is noted that if a center/FLC list was requested at step SI 70024, step 
15 S 170030 is executed to send the list of available centers and FLCs via the TCP/IP 
sockets, before executing step SI 70026. 

Similarly, if it is a new Greta user, at step S 1 70026, step S 1 7003 1 is executed 
to send all data for the center/FLC requested via the TCP/IP sockets before executing 
stepS 170027. 
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a sample OSSPND screen is shown at page 6-195 of the aforementioned 
M Work and Force Administration/Control (WFA/C) User Manual". 
Specify Ticket 

The specify ticket activity routine is illustrated in Fig. 31. When this activity 
routine is selected, a specify ticket window pops up that permits the user to select a 
ticket. In particular* the system obtains the user's input. The user has four options: 

- select the "OK" button, 

- select the "EXIT" button, 

- Press the "Return" key, or 

- Select a Previous ticket. 

If the "Return" (also referred to as "Enter") key was entered while In the ticket field, 
a determination is made as to whether the user is logged into the selected region. 
When this determination is affirmative, a request is made for either a WFA/C 
Maintenance Pool Worklist (OSSAVL) window or a WFA/C Trouble Report/Activity 
(OSSTR) window. If the OSSAVL window is brought up, the user selects the line 
containing the desired ticket. The selected ticket is then placed in the Specified 
Ticket window and processing returns to get additional user inputs (steps SI 80002 to 
SI 800 18). 
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On the other hand, if the OSSTR window is brought up (i.e., no for step 
S 1 800 1 0) (or the "OK" button was selected by the user), the presently displayed ticket 
is made active for all ticket actions, and then the Specify ticket window closes (steps 
SI 80002 to SI 800 10, SI 80020 and S 180022. 

It is noted that if the user decides to select the "Exit" button, processing jumps 
to step SI 80022, to close this window. 

Specify Circuit Window 

The Specify Circuit Window activity flowchart is illustrated in Fig. 32. In this 
window, the current specified circuit is displayed. The user can then input partial CID * 
data, CLO data, Order Number, or CAC data. The user then has several options: 

- find a circuit id (step SI 90004), 

- clear the user input (S 1 90006), 

- test the specified circuit (SI 90008), 

- load REACT 200 1 (S 1 900 1 0), 

- get circuit information (SI 900 12), or 
-exit (Si 900 14). 

If the user elected to find a circuit id, and the user is logged into the region, a 
WFA process is initiated to find the circuit id. When the circuit id is found, an 
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appropriate message is produced, and processing loops back to display the current 
specified circuit (steps SI 90004 to SI 90008). 
Pickup Ticket 

The flowchart for executing the pickup ticket is shown in Fig. 34. As shown 
5 in the drawing, when this activity routine is selected, the user selects a desired region, 
and the WFA/C Trouble Report/Activity (OSSTR) screen is activated using the 
obtained ticket (steps S20000 to S20005). However, if the user is not logged into the 
region (step S20006), or it was not possible to successfully execute the WFA/C 
Pickup using the selected region (step S20007), an appropriate error message is 
1 0 produced and this process ends (step S20008). 
OSSTR Window 

The program for performing the WFA/C Trouble Report/Activity (OSSTR) 
activity window is shown in Figs. 37-39. a center technician (user) works on trouble 
reports from this window (screen). That is, this window allows the user to, for 
15 example, initiate handoffs, test requests, and make referrals to other centers. 

In operation, when a ticket has been specified, the OSSTR activity window is 
initiated using the specified ticket, and the OSSTR window is displayed. From the 
OSSTR window, the user (technician) selects a process from among the following: 

- refresh the OSSTR screen, 
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- send the ticket number to the OSSLOG process window, 
-send the ticket to the OWDDOC process window, 

- send the ticket to the OSSTRE process window, 

- grab the ticket, 
5 - drop the ticket, 

- add a remark (see Fig. 43), 

- dispatch the ticket (see Fig. 44), 

- activate a status process (see Fig. 46), 

- closeout the process (see Fig. 45), 
10 . - send the ticket to a printer, 

- initiate a test process, 

- activate a semi-automatic test process (see Fig. 42), 

- display circuit information, 

- display a command menu, or 
15 -exit. 

It is noted that if the user grabs the ticket (step S210018), the OSSTR screen 
is refreshed. Further, if the user (technician) selects the display commands option, the 
user is presented with three choices: 

- cancel the ticket (step S2 10050), 
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- get the next ticket on the list (step S2 10052), or 

- go to the top of the day ticket (e.g., first ticket of the day) (step S2 10054). 
The Semi-Automatic Test activity routine (step S2 10032 in Fig. 38) is shown 

in Fig. 42. In this routine, the semi-automatic window is brought up, providing the 
5 user with several options, as follows: 

- submit a ticket, 

- clear the form, 

- pop up a list window of semi-automatic information, or 

- exit this window. 

10 If the user submits a ticket and he/she is logged in, the ticket and CLO (circuit -layout 

order number) is submitted, a confirmation message is produced, and this window 

closes (steps S2 100343 to S2 1003 46) 

The add remark activity routine (step S2 10022 in Fig. 38), is shown in greater 

detail in Fig. 43. According to this routine, a window pops up that allows a user to 
15 append a remark to the log. Thereafter, this window is closed (steps S2 100221 to 

S2100224. 

The dispatch activity routine (step S2 10024 in Fig.38) is selected when the 
user wishes to update the OSSTR-with dispatch information. This routine is 
illustrated in greater detail in Fig. 44. 
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The status activity routine (step S2 10026 in Fig. 38) is shown in greater detail 
in Fig. 46. According to this routine, the user is able to call up the WFA/C Trouble 
Report/Activity (OSSTR) window and update it with status information. 

The close out activity routine (step S2 10028 in Fig. 38) is shown in greater 
5 detail in Fig. 45. This routine is executed to update the WFA/C Trouble 
Report/Activity (OSSTR) window with close out information before exiting this 
routine. 

WFA/C Screens Bv Ticket 

The WFA/C Screens By Ticket activity window is illustrated in Fig. 36. When 
1 0 this window is selected, the user can select from the following: 

- History Measurement Data (OSSHMD), 

- Service Order Image (OSSDV1G), 

- Line Record Display (OSSLR), 

- WFA/C Multipoint Circuit List (OSSML), 
15 - Multipoint Index (VJMPI), 

- WFA/C Trouble Report Entry (OSSTRE), 

- WFA/C Trouble Report Electronic Bonding (OSSTREB), 

- WFA/C Trouble Report/Activity (OSSTR), 

- WORD Access Screen (OWDDOC), 
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- WFA/C Work log (OSSLOG), 

- Customer Credit Allowance (OSSCCA), 

- Circuit History (OSSCHI), 

- Circuit Notes (OSSCN), 

5 - Customer Service Charge (OSSCSC); and 

- Facility Find (OSSFF). 

Several of these options were previously discussed with respect to the WFA/C 
Screens By Circuit window (see Fig. 35), and thus, oal^ke only the options that were 
not previously discussed will be discussed below. 

10 The WFA/C Authorization (OSS AUTH) window, step S2402, (the flowchart 

of which is illustrated in Fig. 50) allows the user to automatically collect and display 
data associated with inter-exchange carrier (IEC) customer authorization requests. 
This window also collects and displays approval or denial of authorization requests 
for Electronic Bonding (EB) trouble reports, a sample OSSAUTH screen is shown 

15 at page 6-52 of the aforementioned "Work and Force Administration/Control 
(WFA/C) User Manual". 

The NSDB Multipoint Circuit Index Format (VJMPI) activity routine (step 
S2404), illustrated in Fig. 51, is a view-only screen that displays (and prints) 
multipoint index circuit data (also referred to as an Index Page). This screen displays 
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critical information about complex circuit arrangements, a sample screen (window) 
is shown at page 4- 1 1 of the aforementioned " Work and Force Administration/Control 
(WFA/C) User Manual". 

The WFA/C Trouble Report Electronic Bonding (OSSTREB) activity window, 
5 the flowchart of which is illustrated in Fig. 52, provides for the collection and storage 
of additional IEC-provided data, such as, for example, information transmitted to 
WFA/C via a gateway by an IEC or other customer. Electronic Bonding allows a user 
to take trouble reports from IECs directly via terminal emulation over an electronic 
gateway. An IEC technician can enter IEC trouble report information in an OSSTRE- 

10 type format. The TR information is passed from the IEC gateway to the BCC via a 
gateway, and from the BCC gateway to WFA/C. When the information (data) 
reaches the WFA/C system, the trouble report information is displayed in the 
OSSTRE and OSSTREB formats, and stored in the Trouble Databases. 

The flowchart of the WFA/C Work Log (OSSLOG) activity routine is 

15 illustrated in Fig. 48. This window (screen) is a display-only screen that shows a 
detailed account of activities on an order or trouble report. In the disclosed 
embodiment, this window shows activities in a date/time sequence, with the most 
recent activity being at the top of the display. 
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The flowchart for the Customer Credit Allowance (OSSCCA) activity window 
and the Customer Service Charge (OSSCSC) activity window is shown in Fig. 49. 
The OSSCCA window allows the user to initiate a customer rebate when a trouble 
duration is greater than a required rebate interval. The OSSCSC window allows the 
5 user to enter customer billing information and to describe work performed by 
technicians. This data is used by an Accounting Office for billing purposes. 

Based upon the above discussion with respect to Figs. 4-63, GRETA executes 
procedures on the WFA Host. The procedures are executed in accordance with 
known functionalities of the WFA Host. To execute a WFA procedure, GRETA 
1 0 provides an appropriate user interface to populate data to be formatted and transferred 
(if necessary) to the WFA Host to run the procedure. Once the WFA Host has 
completed the procedure, data returned to GRETA is formatted and displayed (if 
necessary) on the appropriate interface. 

When GRETA calls HILDA to perform tests on ISDN switches, HILDA 
15 interfaces with Network Monitoring and Analysis System (NMA). NMA is a product 
of Bellcore, Murray Hill, New Jersey. The ISDN switch testing procedures (shown 
in Fig. 65) are executed in accordance with known scripts executed on the NMA Host. 
HILDA provides a system wherein multiple tests may be performed on the NMA 
Host simultaneously. To execute a NMA testing procedure, GRETA, via HILDA, 
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provides an appropriate user interface to populate data to be formatted and transferred 
(if necessary) to the Ni^T Host to run the testing procedure. Once the NMA Host has 
completed the testing procedure, data returned to GRETA, via HILDA, is formatted 
and displayed (if necessary) on the appropriate interface. 
5 When GRETA calls the REACT 200 1 Host to perform remote teeing of digital 

and analog services (e.g., private lines), GRETA provides an appropriate user 
interface to populate data to be formatted and transferred (if necessary) to the REACT 
2001 Host to run the remote testing procedure.^ Once the REACT 2001 Host has 
completed the renjote testing procedure, data returned to GRETA is formatted and 

1 0 displayed (if necessary) on the appropriate interface. 

Other procedures shown in Figs. 4-63 execute functions and routines (e.g., 
dynamically linked library functions) provided by an AIX (or equivalent) operating 
system and software running on the RS6000 platform. For example, windowing 
software, such as X-Windowing software (e.g., X-Motif), may be provided to create 

15 the GRETA and HILDA user interfaces. Accordingly, procedures to resize, 
reposition, and change window colors may be provided by such windowing software. 
Further, procedures to access attached devices (e.g., printers) may be provided by the 
AIX operating system. Still further, client software such as wordprocessors and 
browsers, etc. may be implemented by known client software programs (e.g, 
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MICROSOFT WORD and MOSAIC or other HTML compatible browsers). Other 
features and processes may be provided by applications bundled with the operating 
system (e.g., UNIX mail, UNIX Telnet, UNIX FTP, and UNIX man pages). Also, 
other high level programming languages, such as HLLAPI, which are compatible with 
5 UNIX based operating systems may be used. Additionally, security and access to the 
system may be limited in accordance with UNIX security and access features (e.g., 
UNIX rlogin, and UNIX yppasswrd). 

While the invention has been described with reference to a preferred 
embodiment, it is understood that the words which have been used herein are words 

10 of description and illustration, rather than words of limitations. Changes may be 
made, without departing from the scope and spirit of the invention in its aspects. 
Although the invention has been described herein with reference to particular 
hardware, software, means, materials and embodiments, the invention is not intended 
to be limited to the particulars disclosed herein; rather, the invention extends to all 

15 functionally equivalent structures, methods and uses. 

For example, hardware platforms other than the IBM RS6000 and 3270 may 
be used. In addition, other software applications may be used to implement the user 
interface of the present invention than the exemplary applications provided above. 
Further, other communications protocols may be utilized to transport data from one 
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system to another. In addition, the present invention is not limited to interfacing with 
HILDA, WFA and REACT 2001 Hosts, as the present invention may communication 
with other Hosts utilizing the interface techniques of the present invention to format 
and transfer data. Still further, the system of the present invention may notify 
5 administrative personnel of errors via other processes than paging, for example, the 
system may notify administrative personnel via E-mail and voicemail. 
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